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Abstract 


This document contains recommendations from the Internet Engineering 
Task Force (IETF) IPv6 Working Group to the Third Generation 
Partnership Project (3GPP) community regarding the use of IPv6 in the 
3GPP standards. Specifically, this document recommends that the 3GPP 
specify that multiple prefixes may be assigned to each primary PDP 
context, require that a given prefix must not be assigned to more 
than one primary PDP context, and allow 3GPP nodes to use multiple 
identifiers within those prefixes, including randomly generated 
identifiers. 


The IPv6 Working Group supports the use of IPv6 within 3GPP and 
offers these recommendations in a spirit of open cooperation between 
the IPv6 Working Group and the 3GPP community. Since the original 
publication of this document as an Internet-Draft, the 3GPP has 
adopted the primary recommendations of this document. 


Conventions Used In This Document 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOI", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 


document are to be interpreted as described in BCP 14, RFC 2119 
[KEYWORD]. 
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1. Introduction 


In May 2001, the IPv6 Working Group (WG) held an interim meeting in 
Redmond, WA to discuss the use of IPv6 within the 3GPP standards. 

The first day of the meeting was a joint discussion with 3GPP, during 
which an architectural overview of 3GPP’s usage of IPv6 was 
presented, and there was much discussion regarding particular aspects 
of IPv6 usage within 3GPP. At that meeting, a decision was made to 
form a design team to write a document offering advice from the IPv6 
WG to the 3GPP community, regarding their use of IPv6. This document 
is the result of that effort. 


This document offers recommendations to the 3GPP community from the 
IETF IPv6 Working Group. It is organized into three main sections: 


1. An introduction (this section) that provides background 
information regarding the IETF IPv6 WG and the 3GPP and 
includes a high-level overview of the technologies discussed in 
this document. 
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2. Recommendations from the IPv6 WG to the 3GPP community. These 
can be found in section 2. 


3. Further work items that should be considered by the IPv6 WG. 
These items are discussed in section 3. 


It is the purpose of this document to provide advice from the IPv6 
Working Group to the 3GPP community. We have limited the contents of 
this document to items that are directly related to the use of IPv6 
within 3GPP. This document defines no standards, and it is not a 
definitive source of information regarding IPv6 or 3GPP. We have not 
chosen to explore 3GPP-related issues with other IETF protocols 
(i.e., SIP, IPv4, etc.), as they are outside the scope of the IPv6 
Working Group. 


The IPv6 Working Group fully supports the use of IPv6 within 3GPP, 
and we encourage 3GPP implementers and operators to participate in 
the IETF process. We are offering these suggestions in a spirit of 
open cooperation between the IPv6 Working Group and the 3GPP 
community, and we hope that our ongoing cooperation will help to 
strengthen both sets of standards. 


The 3GPP address allocation information in this document is based on 
the 3GPP document TS 23.060 version 4.1.0 [OLD-TS23060]. At the 3GPP 
plenary meeting TSG #15 in March 2002, the 3GPP adopted the two 
primary recommendations contained in this document, allocating a 
unique prefix to each primary PDP context when IPv6 stateless address 
autoconfiguration is used, and allowing the terminals to use multiple 
interface identifiers. These changes were retroactively applied from 
3GPP release 99 onwards, in TS23.060 versions 3.11.0, 4.4.0 and 5.1.0 
[NEW-TS23060]. 


1.1 What is the 3GPP? 


The Third Generation Partnership Project (3GPP) is a global 
standardization partnership founded in late 1998. Its Organizational 
Partners have agreed to co-operate in the production of technical 
specifications for a Third Generation Mobile System, based on the 
evolved GSM core networks. 


The 3GPP Organizational Partners consist of several different 
standardization organizations: ETSI from Europe, Standards Committee 
T1 Telecommunications (T1) in the USA, China Wireless 
Telecommunication Standard Group (CWTS), Korean Telecommunications 
Technology Association (TTA), the Association of Radio Industries and 
Businesses (ARIB), and the Telecommunication Technology 

Committee (TTC) in Japan. 
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The work is coordinated by a Project Co-ordination Group (PCG), and 
structured into Technical Specification Groups (TSGs). There are 
five TSGs: Core Network (TSG CN), Radio Access Networks (TSG RAN), 
Services and System Aspects (TSG SA), GSM/EDGE Radio Access Network 
(GERAN), and the Terminals (TSG T). The TSGs are further divided 
into Working Groups (WGs). The technical work is done in the working 
groups, and later approved in the TSGs. 


3GPP working methods are different from IETF working methods. The 
major difference is where the majority of the work is done. In 3GPP, 
the work is done in face-to-face meetings, and the mailing list is 
used mainly for distributing contributions, and for handling 
documents that were not handled in the meeting, due to lack of time. 
Decisions are usually made by consensus, though voting does exist. 
However, it is rather rare to vote. 3GPP documents are public and 
can be accessed via the 3GPP web site [3GPP-URL]. 


1.2 What is the IETF? 


The Internet Engineering Task Force (IETF) is a large, open, 
international community of network designers, operators, vendors, and 
researchers, concerned with the evolution of the Internet 
architecture and the smooth operation of the Internet. The IETF is 
also the primary standards body developing Internet protocols and 
standards. It is open to any interested individual. More 
information about the IETF can be found at the IETF web site [IETF- 
URL]. 


The actual technical work of the IETF is done in working groups, 
organized by topic into several areas (e.g., routing, transport, 
security, etc.). The IPv6 Working Group is chartered within the 
Internet area of the IETF. Much of the work is handled via mailing 
lists, and the IETF holds meetings three times per year. 

1.3 Terminology 
This section defines the 3GPP and IETF terminology used in this 
document. The 3GPP terms and their meanings have been taken from 
[TR21905]. 

did de 3GPP Terminology 


APN Access Point Name. The APN is a logical name referring 
to a GGSN and an external network. 


ES Circuit Switched 


GERAN GSM/EDGE Radio Access Network 
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GGSN 


GPRS 


GTP-U 


MT 


PDP 


PDP Context 


PS 


SGSN 


TE 


UE 


UMTS 


USIM 


UTRAN 


732 


IPv6 


NAS 


NAT 


NAT-PT 


PPP 


SIIT 
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Gateway GPRS Support Node. A router between the GPRS 


network and an external network (i.e., the Internet). 
General Packet Radio Services 
General Tunneling Protocol - User Plane 


Mobile Termination. 
handset. 


For example, a mobile phone 


Packet Data Protocol 

A PDP connection between the UE and the GGSN. 
Packet Switched 

Serving GPRS Support Node 


Terminal Equipment. For example, 
through a 3GPP handset. 


a laptop attached 


User Equipment (TE + MT + USIM). An example would be 
a mobile handset with a USIM card inserted and a 
laptop attached. 

Universal Mobile Telecommunications System 


Universal 
card that 


Subscriber Identity Module. Typically, a 
is inserted into a mobile phone handset. 


Universal Terrestrial Radio Access Network 


IETF Terminology 


Internet Protocol version 6 [RFC 2460] 
Network Access Server 


Network Address Translator 


Network Address Translation with Protocol Translation. 
An IPv6 transition mechanism. [NAT-PT] 
Point-to-Point Protocol [PPP] 


Stateless IP/ICMP Transition Mechanism [SIIT] 
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1.4 Overview of the IPv6 Addressing Architecture 


The recommendations in this document are primarily related to IPv6 
address assignment. To fully understand the recommended changes, it 
is necessary to understand the IPv6 addressing architecture, and 
current IPv6 address assignment mechanisms. 


The IPv6 addressing architecture represents a significant evolution 
from IPv4 addressing [ADDRARCH]. It is required that all IPv6 nodes 
be able to assemble their own addresses from interface identifiers 
and prefix information. This mechanism is called IPv6 Host 
Autoconfiguration [AUTOCONF], and it allows IPv6 nodes to configure 
themselves without the need for stateful configuration servers (i.e., 
DHCPv6) or statically configured addresses. 


Interface identifiers can be globally unique, such as modified EUI-64 
addresses [ADDRARCH], or non-unique, such as randomly generated 
identifiers. Hosts that have a globally unique identifier available 
may also choose to use randomly generated addresses for privacy 
[PRIVADDR] or for other reasons. IPv6 hosts are free to generate new 
identifiers at any time, and Duplicate Address Detection (DAD) is 
used to protect against the use of duplicate identifiers on a single 
link [IPV6ND]. 


A constant link-local prefix can be combined with any interface 
identifier to build an address for communication on a locally 
attached link. IPv6 routers may advertise additional prefixes 
(site-local and/or global prefixes) [IPV6ND]. Hosts can combine 
advertised prefixes with their own interface identifiers to create 
addresses for site-local and global communication. 


IPv6 introduces architectural support for scoped unicast addressing 
[SCOPARCH]. A single interface will typically have multiple 
addresses for communication within different scopes: link-local, 
site-local and/or global [ADDRARCH]. Link-local addresses allow for 
local communication, even when an IPv6 router is not present. Some 
IPv6 protocols (i.e., routing protocols) require the use of link- 
local addresses. Site-local addressing allows communication to be 
administratively contained within a single site. Link-local or 
site-local connections may also survive changes to global prefix 
information (e.g., site renumbering). 


IPv6 explicitly associates each address with an interface. 
Multiple-interface hosts may have interfaces on more than one link or 
in more than one site. Links and sites are internally identified 
using zone identifiers. Proper routing of non-global traffic and 
proper address selection are ensured by the IPv6 scoped addressing 
architecture [SCOPARCH]. 
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IPv6 introduces the concept of privacy addresses [PRIVADDR]. These 
addresses are generated from an advertised global prefix anda 
randomly generated identifier, and are used for anonymous access to 
Internet services. Applications control the generation of privacy 
addresses, and new addresses can be generated at any time. 


The IPv6 site renumbering specification [SITEREN] relies upon the 
fact that IPv6 nodes will generate new addresses when new prefixes 
are advertised on the link, and that they will deprecate addresses 
that use deprecated prefixes. 


In the future, additional IPv6 specifications may rely upon the 
ability of IPv6 nodes to use multiple prefixes and/or multiple 
identifiers to dynamically create new addresses. 


1.5 An IP-Centric View of the 3GPP System 


The 3GPP specifications define a Third Generation Mobile System. An 
overview of the packet switched (PS) domain of the 3GPP Release 99 
system is described in the following sections. The authors hope that 
this description is sufficient for the reader who is unfamiliar with 
the UMTS packet switched service, to understand how the UMTS system 
works, and how IPv6 is currently defined to be used within it. 


TDi dh Overview of the UMTS Architecture 
The UMTS architecture can be divided into two main domains -- the 
packet switched (PS) domain, and the circuit switched (CS) domain. 


In this document, we will concentrate on the PS domain, or General 
Packet Radio Services (GPRS). 


| TE | 
| 
+R 
| 
SaaS UUs. Henga TU: SASS SaS SSA GHU SES TSE Gi 
| MT |--+-- UTRAN --+-- SGSN --+-- GGSN --+-- 
(UE) 


Figure 1: Simplified GPRS Architecture 
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Figure 2: 
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Figure 3: Laptop Attached to 3GPP Handset 


The GPRS core network elements, shown in Figures 1 and 2, are the 
User Equipment (UE), Serving GPRS Support Node (SGSN), and Gateway 


GPRS Su 
Control 


GGSN: 


SGSN: 


Wasserman 


pport Node (GGSN). The UTRAN comprises Radio Access Network 
lers (RNC) and the UTRAN base stations. 


A specialized router that functions as the gateway between the 
GPRS network and the external networks, e.g., Internet. TE 
also gathers charging information about the connections. In 
many ways, the GGSN is similar to a Network Access Server 
(NAS). 


The SGSN's main functions include authentication, 
authorization, mobility management, and collection of billing 
information. The SGSN is connected to the SS7 network and 
through that, to the Home Location Register (HLR), so that it 
can perform user profile handling, authentication, and 
authorization. 
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GTP-U: A simple tunnelling protocol running over UDP/IP and used to 
route packets between RNC, SGSN and GGSN within the same, or 
between different, UMTS backbone(s). A GTP-U tunnel is 
identified at each end by a Tunnel Endpoint Identifier (TEID). 


Only the most significant elements of the GPRS system are discussed 
in this document. More information about the GPRS system can be 
found in [OLD-TS23060]. 


Mi The PDP Context 


The most important 3GPP concept in this context is a PDP Context. A 
PDP Context is a connection between the UE and the GGSN, over which 
the packets are transferred. There are two kinds of PDP Contexts -- 
primary, and secondary. 


The primary PDP Context initially defines the link to the GGSN. For 
instance, an IP address is assigned to each primary PDP Context. In 
addition, one or more secondary PDP Contexts can be added to a 
primary PDP Context, sharing the same IP address. These secondary 
PDP Contexts can have different Quality of Service characteristics 
than the primary PDP Context. 


Together, a primary PDP Context and zero or more secondary PDP 
Contexts define, in IETF terms, a link. GPRS links are point-to- 
point. Once activated, all PDP contexts have equal status, meaning 
that a primary PDP context can be deleted while keeping the link 
between the UE and the GGSN, as long as there are other (secondary) 
PDP contexts active for the same IP address. 


There are currently three PDP Types supported in GPRS -- IPv4, IPv6, 
and PPP. This document will only discuss the IPv6 PDP Type. 


There are three basic actions that can be performed on a PDP Context: 
PDP Context Activation, Modification, and Deactivation. These 
actions are described in the following. 
Activate PDP Context 
Opens a new PDP Context to a GGSN. If a new primary PDP 
Context is activated, there is a new link created between a UE 
and a GGSN. A UE can open multiple primary PDP Contexts to one 
or more GGSNs. 


Modify PDP Context 


Changes the characteristics of a PDP Context, for example QoS 
attributes. 
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Deactivate PDP Context 


Deactivates a PDP Context. If a primary PDP Context and all 
secondary PDP contexts associated with it are deactivated, a 
link between the UE and the GGSN is removed. 


The APN is a name which is logically linked to a GGSN. The APN may 
identify a service or an external network. The syntax of the APN 
corresponds to a fully qualified domain name. At PDP context 
activation, the SGSN performs a DNS query to find out the GGSN(s) 
serving the APN requested by the terminal. The DNS response contains 
a list of GGSN addresses from which the SGSN selects one (ina 
round-robin fashion). 


| LINK 1 
========= PDP Context A ========- - 


- | LINK 2 J - = 


MT 
(handset) 


LINK 3 | 


| 
| 
========= PDP Context D ========- | 
| 
- -> ISP Z 


| LINK 4 | 
- PPP====----- PDP Context E ========- 


Figure 3: Correspondence of PDP Contexts to IPv6 Links 
3 IPv6 Address Autoconfiguration in GPRS 


GPRS supports static and dynamic address allocation. Two types of 
dynamic address allocation are supported -- stateless, and stateful. 
Stateful address configuration uses an external protocol to connect 
to a server that gives the IP address, e.g., DHCP. 
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The stateless IPv6 autoconfiguration works differently in GPRS than 
in Ethernet networks. GPRS nodes have no unique identifier, whereas 
Ethernet nodes can create an identifier from their EUI-48 address. 
Because GPRS networks are similar to dialup networks, the stateless 
address autoconfiguration in GPRS was based on PPPv6 [PPPV6]. 


3GPP address autoconfiguration has the following steps: 


1. The Activate PDP Context message is sent to the SGSN (PDP 
Type=IPv6, PDP Address = 0, etc.). 


2. The SGSN sends a Create PDP Context message to the GGSN with 
the above parameters. 


3. GGSN chooses an interface identifier for the PDP Context and 
creates the link-local address. It answers the SGSN with a 
Create PDP Context response (PDP Address = link-local address). 


4. The SGSN sends an Activate PDP Context accept message to the UE 
(PDP Address = link-local address). 


5. The UE keeps the link-local address, and extracts the interface 
identifier for later use. The UE may send a Router 
Solicitation message to the GGSN (first hop router). 


6. After the PDP Context Activation, the GGSN sends a Router 
Advertisement to the UE. 


7. The UE should be configured not to send a Neighbor Solicitation 
message. However, if one is sent, the GGSN will silently 


discard it. 


8. The GGSN updates the SGSN with the whole IPv6 address. 


Each connected handset or laptop will create a primary PDP context 
for communication on the Internet. A handset may create many primary 
and/or secondary PDP contexts throughout the life of its connection 
with a GGSN. 


Within 3GPP, the GGSN assigns a single 64-bit identifier to each 
primary PDP context. The GGSN also advertises a single /64 prefix to 
the handset, and these two items are assembled into a single IPv6 
address. Later, the GGSN modifies the PDP context entry in the SGSN 
to include the whole IPv6 address, so that the SGSN can know the 


single address of each 3GPP node (e.g., for billing purposes). This 
address is also used in the GGSN to identify the PDP context 
associated with each packet. It is assumed that 3GPP nodes will not 
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generate any addresses, except for the single identifier/prefix 
combination assigned by the GGSN. DAD is not performed, as the GGSN 
will not assign the same address to multiple nodes. 


2 Recommendations to the 3GPP 


In the spirit of productive cooperation, the IPv6 Working Group 
recommends that the 3GPP consider three changes regarding the use of 
IPv6 within GPRS. Specifically, we recommend that the 3GPP: 


1. Specify that multiple prefixes may be assigned to each primary 
PDP context, 


2. Require that a given prefix must not be assigned to more than 
one primary PDP context, and 


3. Allow 3GPP nodes to use multiple identifiers within those 
prefixes, including randomly generated identifiers. 


Making these changes would provide several advantages for 3GPP 
implementers and users: 


Laptops that connect to 3GPP handsets will work without any 
software changes. Their implementation of the standard IPv6 over 
PPP, address assignment, and autoconfiguration mechanisms will 
work without any modification. This will eliminate the need for 
vendors and operators to build and test special 3GPP drivers and 
related software. As currently specified, the 3GPP standards will 
be incompatible with laptop implementations that generate their 
own identifiers for privacy or other purposes. 


IPv6 software implementations could be used in 3GPP handsets 
without any modifications to the IPv6 protocol mechanisms. This 
will make it easier to build and test 3GPP handsets. 


Applications in 3GPP handsets will be able to take advantage of 
different types of IPv6 addresses (e.g., static addresses, 
temporary addresses for privacy, site-scoped addresses for site 
only communication, etc.) 


The GPRS system will be better positioned to take advantage of new 
IPv6 features that are built around the current addressing 
architecture. 


2.1 Limitations of 3GPP Address Assignment 


The current 3GPP address assignment mechanism has the following 
limitations: 
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The GGSN only advertises a single /64 prefix, rather than a set of 
prefixes. This will prevent the participation of 3GPP nodes 
(e.g., handsets or 3GPP-attached laptops) in IPv6 site 
renumbering, or in other mechanisms that expect IPv6 hosts to 
create addresses based on multiple advertised prefixes. 


A 3GPP node is assigned a single identifier and is not allowed to 
generate additional identifiers. This will prevent the use of 
privacy addresses by 3GPP nodes. This also makes 3GPP mechanisms 
not fully compliant with the expected behavior of IPv6 nodes, 
which will result in incompatibility with popular laptop IPv6 
stacks. For example, a laptop that uses privacy addresses for web 
browser connections could not currently establish a web browser 
connection over a 3GPP link. 


These limitations could be avoided by enabling the standard IPv6 
address allocation mechanisms in 3GPP nodes. The GGSN could 
advertise one or more prefixes for the local link in standard IPv6 
Router Advertisements, and IPv6 addresses could be assembled, as 
needed, by the IPv6 stack on the handset or laptop. An interface 
identifier could still be assigned by the GGSN, as is currently 
specified in the 3GPP standards. However, the handset or laptop 
could generate additional identifiers, as needed for privacy or other 
reasons. 


2.2 Advertising Multiple Prefixes 


For compliance with current and future IPv6 standards, the IPv6 WG 
recommends that the 3GPP allow multiple prefixes to be advertised for 
each primary PDP context. This would have several advantages, 
including: 


3GPP nodes could participate in site renumbering and future IPv6 
mechanisms that rely on the use of multiple global prefixes ona 
single link. 


Site-local prefixes could be advertised on 3GPP links, if desired, 
allowing for site-constrained communication that could survive 
changes to global prefix information (e.g., site renumbering). 


2.3 Assigning a Prefix to Only One Primary PDP Context 


The IPv6 WG recommends that the 3GPP treat a primary PDP context, 
along with its secondary PDP contexts, as a single IPv6 link, and 
that the GGSN view each primary PDP context as a single subnet. 
Accordingly, a given global (or site-local) prefix should not be 
assigned to more than one PDP context. 
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Because multiple IPv6 hosts may attach through a 3GPP handset, the 
IPv6 WG recommends that one or more /64 prefixes should be assigned 
to each primary PDP context. This will allow sufficient address 
space for a 3GPP-attached node to allocate privacy addresses and/or 
route to a multi-link subnet [MULTLINK], and will discourage the use 
of NAT within 3GPP-attached devices. 


Qiu Is a /64 per PDP Context Too Much? 


If an operator assigns a /64 per PDP context, can we be assured that 
there is enough address space for millions of mobile devices? This 
question can be answered in the positive using the Host Density (HD) 
Ratio for address assignment efficiency [HD]. This is a measure of 
the number of addresses that can practically and easily be assigned 
to hosts, taking into consideration the inefficiencies in usage 
resulting from the various address assignment processes. The HD 
ratio was empirically derived from actual telephone number and data 
network address assignment cases. 


We can calculate the number of easily assignable /64’s making the 
following assumptions: 


An HD ratio of 0.8 (representing the efficiency that can be 
achieved with no particular difficulty). 


Only addresses with the 3-bit prefix 001 (the Aggregatable Global 
Unicast Addresses defined by RFC 2373) are used, resulting in 61 
bits of assignable address space. 


Using these assumptions, a total of 490 trillion (490x10%12) /64 
prefixes can be assigned. This translates into around 80,000 PDP 
Contexts per person on the earth today. Even assuming that a 
majority of these IPv6 /64 prefixes will be used by non-3GPP 
networks, there is still clearly a sufficient number of /64 prefixes. 


Given this, it can be safely concluded that the IPv6 address space 
will not be exhausted if /64 prefixes are allocated to primary PDP 
contexts. 


For more information regarding policies for IPv6 address assignment, 
refer to the IAB/IESG recommendations regarding address assignment 
[IABAA], and the APNIC, ARIN and RIPE address allocation policy 
[AAPOL]. 
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DSZ Prefix Information in the SGSN 


Currently, the 3GPP standards allow only one prefix and one 
identifier for each PDP context. So, the GGSN can send a single IPv6 
address to the SGSN, to be used for billing purposes, etc. 


Instead of using the full IPv6 address to identify a PDP context, the 
IPv6 WG recommends that the SGSN be informed of each prefix that is 
currently assigned to a PDP context. By assigning a prefix to only 
one primary PDP context, the SGSN can associate a prefix list with 
each PDP context. 


2.4 Multiple Identifiers per PDP Context 


The IPv6 WG also recommends that the 3GPP standards be modified to 
allow multiple identifiers, including randomly generated identifiers, 
to be used within each assigned prefix. This would allow 3GPP nodes 
to generate and use privacy addresses, and would be compatible with 
future IPv6 standards that may depend on the ability of IPv6 nodes to 
generate new interface identifiers for communication. 


This is a vital change, necessary to allow standards-compliant IPv6 
nodes to connect to the Internet through 3GPP handsets, without 
modification. It is expected that most IPv6 nodes, including the 
most popular laptop stacks, will generate privacy addresses. The 
current 3GPP specifications will not be compatible with those 
implementations. 


3 Additional IPv6 Work Items 


During our work on this document, we have discovered several areas 
that could benefit from further informational or standards-track work 
within the IPv6 Working Group. 


The IPv6 WG should work to define a point-to-point architecture and 
specify how the standard IPv6 address assignment mechanisms are 
applicable to IPv6 over point-to-point links. We should also review 
and clarify the IPv6 over PPP specification [PPP] to match the 
current IPv6 addressing architecture [ADDRARCH]. 


The IPv6 WG should consider publishing an "IPv6 over PDP Contexts" 
(or similar) document. This document would be useful for developers 


writing drivers for IPv6 stacks to work over 3GPP PDP Contexts. 


The IPv6 working group should undertake an effort to define the 
minimal requirements for all IPv6 nodes. 
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4 Security Considerations 


This document contains recommendations on the use of the IPv6 
protocol in 3GPP standards. It does not specify a protocol, and it 


introduces no new security considerations. 
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Appendix A: Analysis of Findings 


This section includes some analysis that may be useful to 
understanding why the IPv6 working group is making the above 
recommendations. It also includes some other options that were 
explored, and the reasons why those options were less suitable than 
the recommendations outlined above. 


A.1 Address Assignment Solutions 


In order to allow for the configuration and use of multiple IPv6 
addresses per primary PDP Context having different interface 
identifiers, some modifications to the current 3GPP specifications 
would be required. 


The solutions to achieve this were evaluated against the following 
factors: 


- Scarcity and high cost of wireless spectrum 

- Complexity of implementation and state maintenance 
- Stability of the relevant IETF standards 

- Impact on current 3GPP standards 


Two solutions to allow autoconfiguration of multiple addresses on the 
same primary PDP Context were considered: 


1. Assign one or more entire prefixes (/64s) to a PDP Context upon 
PDP Context activation and allow the autoconfiguration of 
multiple addresses. 


a) The assignment may be performed by having the GGSN advertise 
one or more /64 prefixes to the mobile device. 


b) The assignment may be performed by building "prefix 
delegation" functionality into the PDP Context messages or 
by using layer 3 mechanisms such as [PREFDEL]. In this way, 
the prefix is not assigned to the link between the GGSN and 
the mobile device (as in la), but it is assigned to the 
mobile device itself. Note that [PREFDEL] cannot be 
considered stable and has not, at this stage, been adopted 
by the IPv6 WG as a WG document. 


2. Share the same prefix between multiple PDP Contexts connected 
to the same GGSN (and APN). Given that mobile devices may 
generate multiple addresses using more than one interface 
identifier, this would require DAD for the newly generated 
addresses over the air interface, and a proxy DAD, function 
which would increase the complexity and the amount of state to 
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be kept in the GGSN. Also, the GGSN would need to determine 
when the temporary addresses are no longer in use, which would 


be difficult. One possible solution could be using periodic 
unicast neighbor solicitations for the temporary addresses 
[IPV6ND]. 


Considering all the factors when evaluating the solutions, the 
recommendation is to use Solution la. This solution requires the 
least modification to the current 3GPP standards and maintains all 
the advantages of the other solutions. 


Effectively, this would mean that each APN in a GGSN would have a 
certain number of /64 prefixes that can be handed out at PDP context 
Activation, through Router Advertisements. Therefore, instead of 
using the full IPv6 address to identify a primary PDP context, the 
IPv6 WG recommends that the GGSN use the entire prefix (together with 
other 3GPP specific information) and that the SGSN be informed of the 
prefixes that are assigned to a PDP context. By assigning a given 
prefix to only one primary PDP context, the GGSN and SGSN can 
associate a prefix list with each PDP context, as needed. 


Note that the recommended solution does not imply or assume that the 
mobile device is a router. The MT is expected to use the /64 for 
itself and may also use this prefix for devices attached to it. 
However, this is not necessary if each device behind the MT is 
connected to a separate primary PDP Context and therefore can use a 
/64, which is not shared with other devices. The MT is also expected 
to handle DAD locally for devices attached to it (e.g., laptops) 
without forwarding Neighbor Solicitations over the air to the GGSN. 
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